feat: create tags for new revisions published to the store #23
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
A note that one thing we could consider is including the version of the upstream project in the tag, e.g. for Signal we could have something like |
|
+1 for adding the snap version to the tag, this will make it more clear, imo. I'll take a better look at this PR later. |
|
@merlijn-sebrechts version added to tag name in |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Hey 👋
So as discussed in our catch-up meet, here is a first draft of how we might want to create tags automatically in repositories based on the revisions that were released to the store. The aim here is to make debugging issues a little easier, as when an issue is reported on a snap with a given revision, you can just checkout the tag and build/install/troubleshoot.
It's a little complicated with multiple architectures. The design I've chosen is to create one tag per revision, and name with the arch just to make searching/bisecting easier. The tag names will be
rev<num>/<arch>.You can see an example run here and the resulting tags here.
I should note that this is actually a breaking change because all repos that use these workflows will need to add a new input to the release workflow. I think if we merge this, we should tag the repo at
v1, and work on using the actions with a versioned reference like@v1rather than@main.If this does merge, I'll do some follow-up PRs to address the incompatibilities on the other repos.